Heh, reminds me of something that happened last winter at
work.
A county worker had entered an incorrect ZIP code on a client
notice that was generated (but not yet printed) by the mainframe
the previous night. We couldn't programatically correct it as the
'print' dataset had already been built.
So I offered to help by opening the dataset in the 'edit' mode and
manually correcting the ZIP code. I didn't think the fact that the
dataset was 7 GB in size would be an issue, so I fired up a
terminal emulator session and selected the dataset for editing, and
waited. And waited. And waited.
Hmmm... maybe they're having
mainframe access problems now, I thought, so I minimized the
emulator session and proceeded to do other stuff.
About five minutes late, I got a call from a rather irate network
support drone who wanted to know why almost all of the mainframe's
memory buffer pools had my user ID attached to them. She explained
that the buffer pools were used to facilitate disk I/O, and that by
hogging almost all of them, I had caused the mainframe to slow to a
crawl, and county workers throughout the state were calling tech
support to report that their terminal sessions had locked up.
Needless to say, I now know a little more about how the mainframe
'handles' very large files for editing. 
